Debian Jr. development revived Recently there has been some lively discussion on the Debian Jr. list about how to arrange an account for a child of 1 to 3 years of age. Suggestions included using set-top box software like Freevo, tailoring DEs with panels and large buttons, using simpler WMs like fvwm, or using an “activity centre” app like Gcompris. Now, I respect those parents who hold that a child this young should interact more with the “real world”. While I wouldn’t go so far as to outright prohibit my young ones from computer use, I can see the wisdom in keeping it to a minimum. But, for better or worse, our family is one of several who have some experience helping our youngest members use our Debian systems. We would like to share what we’ve learned through the Debian Jr. project. Getting started with live.debian.net To that end, last week I was inspired to follow the Debian Live ISO Howto to produce my first rough draft of a Debian Jr. live CD built from scratch on Etch. For the final product, we’ll want to use a local partial Debian archive mirror, as it not only optimizes fetching packages for several build iterations, but also can be kept stable, which is important as we near release. But for this draft, I ran into trouble building the complete package list to populate the partial mirror, as cdebootstrap, which make-live uses, has no handy --print-debs switch like debootstrap does. So for now, I rely on approx to cache packages for optimization only. A straightforward process to create a working live CD The rest of the process was straightforward: using live-package, I created a package list¹ containing Gnome and the Debian Jr. metapackages, I configured /etc/make-live.conf to point at my proxy, and then I ran the make-live script on the package list. The end result was ./debian-live/binary.iso, which successfully booted under qemu. At this stage, there is not much to show. To be truly useful, the live CD needs to be set up so that children and their guides can immediately find and use the material intended for them. We will need not only one live CD user, but four, varying in age range and role. (More about this in a future article.) However, it is an encouraging start, and shows that we may be able to produce something usable by the time Etch releases.

¹ For this exercise, I simply combined /usr/share/make-live/lists/gnome with the junior-* metapackages in Etch, and added mozilla-firefox-gnome-support to satisfy Gnome’s web browser dependency and cut down on redundancy, resulting in the following list.

junior-art
junior-doc
junior-games-card
junior-games-gl
junior-games-net
junior-games-sim
junior-games-text
junior-gnome
junior-internet
junior-kde
junior-math
junior-programming
junior-puzzle
junior-sound
junior-system
junior-toys
junior-typing
junior-writing
mozilla-firefox-gnome-support
eject sudo
console-common locales
gdm gdm-themes gnome-desktop-environment gnome-cups-manager gnome-screensaver
gnome-themes-extras
rhythmbox synaptic
x-window-system-core

I recently started to be aware of a problem in our family. Ever since we configured Mythgame to run Xmame games, we started to ignore native Linux games. This is a shame, because often the quality of such games is much higher, and besides, they are open source, which I strongly believe in. I looked around for help configuring Mythgame to run Linux games, and was unable to find a way to make a game player that would play any Linux game. So I devised the following solution: Step 1: Set up directories for pseudo-roms, command switches and snapshots

mkdir /usr/share/games/roms
mkdir /usr/share/games/switches
mkdir /usr/share/games/snaps

Step 2: Define a player in Mythgame

Player name: Linux
Type: OTHER
Command: %s  cat \ dirname %s\ /../switches/\ basename %s\ 
Rom Path: /usr/share/games/roms
ScreenShots: /usr/share/games/snaps

Step 3: Populate the directories with data

cd /usr/share/games/roms
ln -s /usr/games/oolite
ln -s /usr/games/starvoyager
cd /usr/share/games/snaps
cp ~synrg/snaps/oolite.png .
cp ~synrg/snaps/starvoyager.png .
cd /usr/share/games/switches
touch oolite
echo "-f" >starvoyager

Step 4: In Mythgame, “Scan for Games” Step 5: Play!

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing¹. Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation², imagemagick and xprop (from xbase-clients):

#!/bin/bash
testname="tuxpaint" 
root_geometry= xprop -root _NET_DESKTOP_GEOMETRY  cut -d= -f2 
root_x= echo $root_geometry  cut -d, -f1 
root_y= echo $root_geometry  cut -d, -f2 
xc=$((root_x/2-1))
yc=$((root_y/2-1))
capture_tuxpaint ()  
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc" 
   xte "mouseclick 1" 
   sleep 1
   xte "key Escape" 
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40" 
   xte "mouseclick 1" 
 
for lang in  tuxpaint --lang help  awk '$1~/^[[:lower:]]/  print $1 ' ; do
   capture_tuxpaint $lang
done

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts). Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists. In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

¹ For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

² I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.

Ideal mobile text editing device redux As I read the responses¹ to my search for the ideal mobile text editing device, reality began to set in. The heating season is now upon us, and even used technology meeting my criteria would likely exceed my stated budget. Furthermore, I’d risk replacing my current issues with a whole new set of issues and end up with a less-than-ideal mobile text editing device. So I have rethought the problem and have decided it would be best to work on with what I have now while I wait for this ideal device to arrive on the market. Keyboard While I can’t change the keyboard of the ZR-5000, with a practiced lighter touch on the keys I can, in fact, touch-type passably well. It has served me well enough to draft several blog articles so far. Software Although not up to the high standard set by Vim, for quick note-taking, I don’t really need a fancy editor. My thoughts flow directly through my fingers into the device with only light editing. Cut-and-paste, motion keys and delete are the bare essentials. Anything more is a frill. Synchronization I do have an ACTiSYS IR-200L infrared dongle for my PC. The trouble is, although this is supported in Linux using IrDA, the ZR-5000 insists on speaking ASK-IR which is not supported. There is a Windows-only program, ZRLink, which might work. I’ll try it either on an XP system at work, (... mixed reviews out there as to whether it will work on recent Windows,) or under Wine. I can get the dialogs to display properly on Wine, but I have my doubts about whether serial emulation works. My initial tests at home under Wine indicate it doesn’t. (Could #277618 have something to do with this?) There is a 15-pin serial connector on the device, but I have no cable for it. And there’s a PCMCIA slot, but compatible devices are likely limited to older, harder-to-find components: either a 2M CF card or a modem card. While I have the latter, it exceeds the power available from batteries and I have no DC adaptor for the unit. Perhaps I overrate synchronization anyway. My best articles are rewritten from scratch more than once. Summary Living in an embarrassingly technology-rich country, it is too easy for a geek like me to convince himself that his gadget cravings are needs whereas, in fact, there is still plenty of life left in the devices he already has. After all, my venerable ZR-5000 was given to me by a fellow who figured if any one of his friends would still be able to use it for something, it would be me. Well, I won’t let him down. I’ll stick with it and make it work. There is one virtue of this device I doubt if any modern device of the same form factor can match. After a week of daily use, I still haven’t had to change the 2 ordinary AA NiMH batteries. Top that.

¹ Thanks, everyone, for your responses. Although there were the inevitable few that mentioned modern devices way over my budget, and I’ve decided now to stick with the ZR-5000, your suggestions did help me bring the real issues into focus.

In the English language, it is so trivial to create new words. In no domain is this quite so evident as the world of computers. Thus, informally amongst Debian users, you’ll often hear “apt-get it” or simply “apt it” which has the virtue of being equally apt a term for using aptitude. Now, I have no problem with people using these verbs. They’re precise, if a bit geeky. But really, shouldn’t there be a more general verb to cover this activity? Back when apt was new, and nobody else was installing packages this way, the lack of a general term made sense. But these days, in certain user communities, you might hear “yum it” instead. How many variants does the English language need? One per apt-like installer? Compare this with the evolution of instant messaging. Back when ICQ dominated the field, “ICQ” was synonymous with instant messaging. These days, although you might occasionally still hear people say “ICQ me” or “Jabber me” (where the protocol is important, because both participants must have access to that specific service) we can more generally say “message me,” encompassing in one fell swoop all possible protocols. Or if you prefer, the awkwardly geeky but more precise term, “IM me” (though arguably slightly less useful than “message me” because it seems to exclude irc, the king of all chat systems). So, what’s the equivalent verb that means “conveniently installing software from one or more software repositories by merely asking for the package by name”? My mind draws a blank.

Dear Lazyweb, I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system. My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university. Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have. At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable. I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780 appears to be another possibility. Have I overlooked anything? So, suggestions please.

Barbicane asked me the other day: “Why Ichthux and Ubuntu CE? Why not consolidate efforts?” As much as I’d like to see Ubuntu CE succeed, I believe they are headed down a path that will make it difficult for them to survive if they continue. In this thread (see Google cache since the forums seem to be having problems today) Jereme severely understates the differences in development philosophies that keep us apart. One key difference is more fundamental than just using metapackages instead of scripts. As I wrote about earlier, the approach Ichthux has chosen is to be a Custom Debian Distribution (CDD), working within Debian and Ubuntu to configure those distributions for the needs of Christians to meet their various needs. This is incompatible with CE’s approach, which uses scripts to tailor an Ubuntu system. This approach risks violating the integrity of the packages being modified, and makes each system upgrade an adventure for the user. What you end up with cannot truly be called an “edition” of Ubuntu at all, but is more accurately described as an Ubuntu derivative. Derivatives are not easily sustained because they are always struggling with staying in sync with the parent distribution. Ubuntu itself is a derivative, but it has an impressive amount of infrastructure with a lot of manpower behind it to ensure that the branching and merging process doesn’t get out of control. I don’t see how the much smaller Ubuntu CE development team will manage to accomplish anything significant using their current approach without being crushed by the maintenance costs of their customizations. Another difference, perhaps more readily apparent to end users, is what’s included in each distribution by default. While CE has chosen the Gnome desktop, Ichthux has gone with KDE. With each new release of Ubuntu CE, it seems what is stressed the most in their release notes is “what’s included”. Well, I just can’t see how that’s terribly important. Debian and Ubuntu both have a vast amount of software available, and both make it easy for users to make choices. If a user wants to add another application, it’s often just a few clicks away. It’s not nearly as important to have these installed by default as it is to ensure that the packages we do include are as solid and well-integrated with the system as possible. To this end, Ichthux makes use of its Debian and Ubuntu developers to ensure that each package included is kept in good shape from release to release. This means addressing bugs and wishlists that matter to our users, improving those packages not just for Ichthux, but for Ubuntu, Debian, and where those fixes flow back upstream, the broader community of Christian FOSS users everywhere. This is the real work of Ichthux: not just the production of a livecd, nor merely tweaking the default selection of packages we include from one release to the next, but to be actively involved in the Christian FOSS developer and user community. Our greatest successes will not be in the degree to which we differentiate ourselves from other Linux distributions, but rather how well we’re listening to what Christian FOSS users are saying they need, and how broad we can make our solutions. We can’t afford to be a niche distribution working off in a corner on our own pet project. That would be a terrible waste of our energy. We’re dreaming big: we want every Christian Linux user to be able to benefit from our work.

I’m reviewing my next actions: dozens of worthy projects waiting for me to do. But I just can’t seem to get moving on any of them. What’s keeping me back? What is so hard about getting things done? Especially with respect to the more rewarding tasks on the list, it’s a mystery that I fail to act. It should be easy. I’ve fretted over this problem for years, yet I’m no closer to an answer today at age forty than when I first discovered my dubious skills many moons ago as a procrastinator extraordinare. Surely all that I need to do is stop worrying and just act—act, and continue to act until to get things done is as natural as breathing. Oh, so simple! So easy to say! I fear I am caught in a cycle of anxiety and inaction that defeats me before I even begin. Faced with my list of next actions, I inexplicably feel anxiety about it with something like the force of physical pain. I balk. I seek out some numbing diversion to get relief: anything but whatever’s at the top of my list. But I know I mustn’t nurse this fear, or it will grow. I will not escape by focusing on how hard it is. So I resolve to nurture hope, to act and not doubt. TODO: Pick any next action. Do it! Repeat.

Whew. Ichthux has released, and now I can breathe again! When I joined the Ichthux development team, they had produced their “proof of concept” release as yet-another-Knoppix-remaster. At that time, I encouraged them to move away from tacking their work on as a derivate of a derivative and instead become a CDD. I argued that as a CDD Ichthux would last, while as a Knoppix-remaster, it would just be another marginal custom livecd that went nowhere. They got the message. So you may well be surprised to hear our first release is based on Kubuntu, and not Debian.

So, what’s the story here? Have you defected?

Nope. It just happens that most of the team ended up being actively involved in Ubuntu development. Also, when we first started casting about for the best way to package a livecd/install disk, it seemed to us that Ubuntu already had a head start on this.

What about being a CDD? It looks to me like that idea has fallen by the wayside.

Nope again. We’re a joint team now, and though we’ve started out with Ubuntu, we’ll be pushing changes back into Debian. The goals of a CDD are well understood by the whole team: to best meet the needs of our users, we design the system to mesh well with the parent distributions, not forking and making a derivative, but working inside those distributions to improve them for our particular subgroup of users.

Hold on now, aren’t you contradicting yourself? A CDD’s development is all within Debian, but Ubuntu itself is a derivative, and what’s worse, Kubuntu is a derivative of a derivative! Aren’t you right back where you started?

Well, on the last count, you’d be wrong. Kubuntu is not a fork. And as for Ubuntu being a derivative, well, sure it is. But the Ubuntu/Debian relationship is different from other derivatives, and although there is friction, I’m enough of a crazy idealist to believe a joint Debian/Ubuntu CDD is quite doable, benefits both projects more, and serves our users better than if we were to split up and each go work on our own.

On the whole I agree with Erich. Subprojects are key to preserving positive energy as a free software project scales. But I wouldn’t say the ill effects suffered by projects as they age is just “a matter of size”. And I wouldn’t de-emphasize the importance of guidelines like the CoC in countering those effects, though I’d agree it does not provide immunity by itself. Ubuntu benefits from the Debian social experiment having started first. So the people involved have the opportunity to learn from and improve on earlier efforts while their project is still young. The CoC is no panacea, but it is a clue that lessons are being learned; deliberate effort needs to be made to keep work fun, especially as a project grows and people begin to lose touch with each other. Putting these lessons into practice isn’t always easy, but I think it would help if as individual developers we’d reflect more on how we interact within our projects and work on making improvements. I appreciate the personal guidelines Erich shared and will adapt them to make them my own.

On #debian-games we were discussing today how opaque cdbs is for those who aren’t intimately acquainted with its inner workings. I want to be able to easily see, at least at the level of detail visible in a purely debhelper-based rules file, what’s going on inside just by running make itself, e.g.

debian/rules -p   grep -v ^#   grep -B1 dh_

Here’s a small excerpt of the output when run on ri-li:

binary-install/ri-li::
        dh_installdocs -p$(cdbs_curpkg) $(DEB_INSTALL_DOCS_ALL) $(DEB_INSTALL_DOCS_$(cdbs_curpkg)) 
        dh_installexamples -p$(cdbs_curpkg) $(DEB_INSTALL_EXAMPLES_$(cdbs_curpkg))
        dh_installman -p$(cdbs_curpkg) $(DEB_INSTALL_MANPAGES_$(cdbs_curpkg)) 
        dh_installinfo -p$(cdbs_curpkg) $(DEB_INSTALL_INFO_$(cdbs_curpkg)) 
        dh_installmenu -p$(cdbs_curpkg) $(DEB_DH_INSTALL_MENU_ARGS)
        dh_installcron -p$(cdbs_curpkg) $(DEB_DH_INSTALL_CRON_ARGS)
...

OK, it’s a bit crude and misses a lot of interesting details, but it is a starting point that can be tweaked to zero in on whatever parts interest you.

XPilot development has changed hands over the past several years. While the original website at www.xpilot.org continues to be run by the original developers, XPilot-NG (xpilot.sf.net) is where all of the new development has been happening. But xpilot.org still performs an important function for the user community: they run the meta servers¹ that list all public xpilot servers around the world. Recently, we (the XPilot-NG developers on #xpilot at irc.freenode.net) noticed quite a number of uncontactable servers popping up on the meta servers. This is annoying, to say the least. Users don’t know they can’t connect until they’ve tried (unless they’ve bothered to try pinging the server first) and besides which, having all those “junk” servers in the list makes it harder to locate contactable servers. Now, naturally, we wanted to know where all of those servers were coming from, and why now, at this particular time? I knew my Debian package (and presumably any derivatives) do not report to the metaserver by default. Any admin starting an XPilot server would have to explicitly configure it to do so, so the incidence of uncontactable Debian XPilot-NG servers should remain relatively low and have a constant growth rate. Then I found the Fedora package, and started poking around inside. After a shallow review of the package, I concluded there was a good chance it was the culprit², especially since it recently (FC5) had an init script added. Such a bug, coupled with the relatively recent release of FC5, would account for the sudden spike in number of permanently running non-contactable XPilot-NG servers. Bingo! I found some helpful folks at #fedora-games at irc.freenode.net, including the XPilot NG maintainer, which led to filing this bug. I subsequently invited the maintainer over to #xpilot and had a nice time introducing him to the other upstream devs and chatting about our current issues. Ultimately, we know we need to fix the problem at the metas, but in the meantime, I am pleased to have established contact with my counterpart in the Fedora project, expanding the diminishingly small XPilot developer community by one.

¹ They deliberately never released any source code for those metas to try to keep the user community unified at the centralized servers. While I see the reasoning behind the decision, given the problems we’re facing now, it’s clear the XPilot community would be better off with meta server source that is actively being maintained.

² Admittedly two problems with the +reportMeta option upstream set us up for this problem. First, counterintuitively, +reportMeta disables reporting to the metaserver (following the rule ”+” negates the meaning of an option starting with ”-”). Second, -reportMeta is a stupid default. Most people starting servers are behind firewalls these days, so unless they consciously decide to make their server public, making the corresponding adjustments to their firewall, the option should not be set (not to mention the security implications of making a server public by default).

Typeahead find in gvim’s GTK+ open dialog box is driving me bananas, but today I discovered a trick I hadn’t seen before that will help work around it with a bit of relearning. For those who aren’t familiar with the problem, John Goerzen describes how painful this feature is for large directories. Just imagine, then, having to regularly deal with large directories on particularly slow, remote filesystems. Argh. Unusable! The trick I came up with to work around the problem is to first enter the path incorrectly and then fix it afterwards. Type a blank first, then the whole filepath, then [Home] to return to the beginning of the line, and finally [Delete] to fix the path, and [Enter] to open the file. It still takes an awfully long time for gvim to read the file, but it’s a great improvement over either trying to type the filename blind, or waiting for each directory to be scanned. Ultimately, these files should be moved off the remote filesystem and into subversion, but there are cross-platform compatibility issues that prevent me from doing this at this time (OpenVMS + Linux + win32). I’m still looking for a real solution. In the comments to John’s post, someone suggested there is a gconf setting that controls this, but so far I haven’t been able to find it. So for now, I’ll have to live with this hack.

Being Father's Day today gives me pause to consider Debian Jr., a project for kids. The goal was to make Debian the OS kids prefer to use. I wanted my own kids to grow up enjoying using a system that puts the fewest barriers in the way to learning about how computers work, and to making computers work for them. It's nearly six years later now: enough time for my second youngest to grow from a toddler to an eight-year-old girl, for my youngest girl to be born and put to the test the lower limit of our "for kids from 0 to 99" slogan, for our boy in the middle to grow from a preschooler to a preteen, and for the two oldest girls to turn into teenagers. Perhaps by the time we have grandkids, Debian Jr. will finally be "done". In that time, our kids have gone from using a VT-420 attached to my Pentium 100, exploring commands using the "magic" tab-key at the bash prompt, playing with words and letters in pico, to playing 3D games and creating artwork in the Gimp on the family Sempron 3300+. And through it all, they've remained happy and proud to use Linux, which none of their friends have. They have become, I believe, more firmly grounded and comfortable with computing than they might have been using a system "dumbed down" for kids. To all the Debian using fathers out there today, Happy Father's Day! May you and your kids' lives be enriched as you share in the finest OS in the world.

I've refocused the Debian Jr. programming metapackage on languages made for kids. I'm sure there are some who have used scheme or python with their kids, and sure, if you want to do that, go ahead. But these were only initially included because of a lack of choices. Littlewizard is an icon-based language only recently added, and kturtle replaces the less-kid-friendly ucblogo. I've also been pursuing #236721 to see what it would take to get Squeak into main. While it doesn't look like there's hope of that anytime soon, recent changes to their licensing might allow it to go into non-free.

Always a tinkerer and an explorer, I've known I wanted to self-host a blog for some time. Blog hosting sites have their pluses, but I couldn't resist making something distinctively mine with cool technology like the Rails-based Typo. Besides, I couldn't be outdone by my wife, who has for months now kept a successful knitting blog. The time has come. Syn.theti.ca will include ideas about programming at work and play, Debian development, home-based learning, kids and family, or whatever else strikes my fancy or seems noteworthy at the time. No lofty goals, in other words. Just a place to collect my thoughts and connect up to the blogosphere.